7 mejores prácticas para acelerar las revisiones de código

Las revisiones de código pueden ser dolorosas. Los ingenieros de software a menudo se quejan de que el proceso de revisión es lento, retrasa las tareas posteriores y conduce a un cambio de contexto a medida que navega de un lado a otro entre una solicitud de extracción abierta (PR) y su próxima tarea. Las revisiones de código también pueden estar llenas de detalles quisquillosos, lo que hace que sea una mala experiencia para todos los involucrados. Para remediar este problema, algunos ingenieros incluso han llegado a sugerir que nos deshagamos de las solicitudes de extracción y las revisiones de código por completo. Si bien eso puede funcionar para equipos pequeños en nuevas empresas, no creo que esta sea la solución adecuada para todos, especialmente para las empresas de nivel empresarial. Más bien, hay muchas maneras en que podemos hacer que el proceso de revisión de código sea una mejor experiencia tanto para el autor del código como para el revisor del código. Consideremos siete de estas mejores prácticas juntas. #1: Mantenga pequeñas las solicitudes de extracción Todos los ingenieros temen revisar las solicitudes de extracción que tienen más de 1000 líneas de código modificadas. Estas revisiones pueden tardar horas en completarse y, a menudo, lo que termina sucediendo es que el revisor comienza a hojear el código en lugar de revisarlo detenidamente. La solución es mantener pequeñas las solicitudes de extracción. Los RP pequeños son más fáciles y rápidos de revisar porque el revisor no necesita dedicar tanto tiempo a construir un modelo mental de cómo funcionan todos los cambios juntos. También se cambia menos el código, lo que con suerte equivale a menos errores, menos comentarios y menos rondas de ida y vuelta entre el autor y el revisor. Mantener tus relaciones públicas pequeñas puede parecer difícil al principio, pero se puede lograr si divides tu trabajo en tareas pequeñas y te mantienes enfocado. No realice refactorizaciones importantes al mismo tiempo que implementa nuevas funciones o corrige errores. Use indicadores de características en su código para que pueda fusionar pequeñas partes de nuevas características en la rama principal sin que aparezcan en la aplicación de producción. Mantenga sus relaciones públicas pequeñas. Sus revisores estarán agradecidos. #2: Use plantillas de solicitud de incorporación de cambios Otra molestia es que se le solicite revisar una solicitud de extracción sin ningún contexto. Cuando te dejan caer un PR sin explicación, a menudo te preguntas: “¿Para qué es este PR? ¿Qué problema está resolviendo esto? ¿Hay una tarea relacionada para esto? ¿Por qué se tomó este enfoque en particular? Una es un formulario pequeño y configurable que puede establecer como texto predeterminado en cada nueva solicitud de extracción. La plantilla de PR solicita al autor del código que proporcione detalles relevantes para su PR. Por lo general, una plantilla de relaciones públicas solicitaría una breve descripción de lo que ha hecho y por qué, un enlace al ticket de la tarea y un plan de prueba para validar los cambios. plantilla de solicitud de extracción Las buenas plantillas de relaciones públicas también suelen incluir una breve lista de verificación para que el autor del código la revise y se asegure de que no se ha perdido ninguno de los aspectos básicos. Esta lista de verificación puede incluir elementos como pruebas unitarias, documentos, internacionalización, compatibilidad con varios navegadores y accesibilidad. A continuación se muestra un ejemplo de plantilla de solicitud de incorporación de cambios que me gusta usar para todos mis repositorios: #3: Implementar SLA de tiempo de respuesta Si descubre que las solicitudes de extracción permanecen sin revisar durante más tiempo del que le gustaría, ahora es un buen momento para establecer expectativas como equipo sobre la rapidez con la que se debe revisar una nueva solicitud de extracción. En otras palabras, ¿cuál es la cantidad máxima de tiempo que puede existir un PR antes de que deba ser recogido? ¿Una hora? ¿Dos horas? ¿24 horas? Su respuesta a esa pregunta probablemente dependerá del tamaño de su equipo. También puede tener una respuesta diferente para las solicitudes de extracción internas de su equipo frente a las solicitudes de extracción externas de otros equipos. Al elegir un SLA (acuerdo de nivel de servicio) de tiempo de respuesta, querrá encontrar el equilibrio adecuado. No es razonable esperar que todos abandonen inmediatamente lo que estén haciendo y revisen su código cuando publique un nuevo PR, pero tampoco desea que los PR permanezcan sin revisar durante horas y horas. Encuentre el equilibrio adecuado que permita a sus compañeros de equipo entrar en un estado de flujo. Deben poder trabajar en su propio código y luego revisar los PR en los puntos de parada naturales a lo largo del día. Personalmente, me gusta tener un SLA de tiempo de respuesta de dos horas para relaciones públicas de equipos internos y un SLA de tiempo de respuesta de 24 horas para relaciones públicas de equipos externos. Independientemente de lo que usted y sus compañeros de equipo decidan, tener un acuerdo de equipo les permite responsabilizarse mutuamente. Si todos acordaron un SLA específico y ese tiempo ha transcurrido para uno de sus PR, sabe que está bien comenzar a molestar a la gente al respecto. #4: Formar ingenieros junior y de nivel medio Las oportunidades de capacitación están en todas partes. Ser mentor de ingenieros con menos experiencia incluye algo más que enseñarles las tecnologías y los lenguajes con los que están trabajando. También incluye enseñarles habilidades blandas como cómo hacer una revisión de código efectiva. Enseñe a sus compañeros de equipo lo que busca durante una revisión de código. Ayúdalos a entender qué es importante y qué no. Enséñeles cómo comunicarse de manera efectiva en sus , como prefijar sugerencias que no bloqueen con "nit". comentarios de revisión de código Hay muchos recursos excelentes sobre cómo ser un revisor de código más eficaz. Vale la pena leer de Google en su totalidad. La guía tiene excelentes consejos tanto para el autor del código como para el revisor del código. Para un recurso más descarado, es fácilmente uno de los mejores (y entretenidos) consejos para los desarrolladores que crean solicitudes de incorporación de cambios. la Guía para desarrolladores de revisión de código Cómo hacer que su revisor de código se enamore de usted #5: Configurar canalizaciones de integración continua Las revisiones de código se vuelven tediosas cuando la mayoría de los comentarios son cosas como "Falta el punto y coma" o "La sangría parece mal aquí". No dedique tiempo durante las revisiones de código a cosas que los formateadores de código y los filtros de código pueden encargarse por usted. Deje que las computadoras automaticen las cosas triviales para que pueda concentrarse en las cosas importantes que requieren un ser humano. Para proyectos de JavaScript, es simple configurar un formateador como y un linter como para su repositorio. Luego puede configurar la integración continua para su repositorio usando algo como , , o . Prettier ESLint Travis CI CircleCI GitHub Actions GitLab CI/CD Su canalización de CI ejecutará estas tareas de formato y linting por usted junto con sus pruebas unitarias. Si la canalización de CI falla en cualquier paso de una solicitud de extracción, bloqueará la fusión de esa solicitud de extracción. Ahora, ha automatizado varias partes importantes de la revisión del código, ahorrándole horas. #6: Use aplicaciones de revisión de solicitud de extracción A veces es necesario no solo revisar el código en una solicitud de incorporación de cambios, sino también ver manualmente los cambios en la aplicación para verificar que las cosas se vean bien. Para aplicaciones con pasos de configuración complejos, extraer el código de otra persona y ejecutarlo localmente en su máquina puede demorar entre cinco minutos y una hora. ¡Que dolor de cabeza! Las se utilizan para implementar automáticamente su código en un entorno de prueba de corta duración cada vez que se crea un nuevo PR. Esto permite a los revisores inspeccionar fácilmente los cambios en la interfaz de usuario sin tener que extraer el código y ejecutarlo localmente en su máquina. Esto no solo ahorra tiempo, sino que también anima a los revisores a ser más minuciosos en sus revisiones al facilitar las cosas. aplicaciones de revisión de solicitud de extracción #7: Genere diagramas para visualizar los cambios de su código Al revisar el código en GitHub o GitLab, los archivos generalmente se muestran en orden alfabético. Para PR relativamente pequeños, esto puede no ser un problema. Pero cuando hay docenas de archivos involucrados en una PR, a veces es útil ver esos cambios agrupados lógicamente para que pueda ver cómo encajan en una imagen más grande. lo ayuda a visualizar qué archivos se cambiaron y cómo esos cambios afectan sus dependencias ascendentes y descendentes. Se integran con GitHub para publicar automáticamente un comentario y un diagrama en su PR. Incluso puede crear recorridos interactivos de su código para ayudar a guiar a sus revisores de código. Lo mejor de todo es que CodeSee Maps es gratuito para las organizaciones de código abierto y sus repositorios públicos. CodeSee Review Maps Conclusión: 7 formas de reducir drásticamente su tiempo en la revisión de código En resumen, aquí hay siete consejos para reducir drásticamente su tiempo en la revisión de código: Mantenga pequeñas las solicitudes de extracción. Use plantillas de solicitud de extracción para proporcionar todo el contexto que necesitaría un revisor. Implementar SLA de tiempo de respuesta. Capacite a los ingenieros junior y de nivel medio sobre las cosas clave que busca durante una revisión de código. Configure canalizaciones de CI para ejecutar linters, formateadores y pruebas unitarias. Use aplicaciones de revisión de solicitud de extracción para que pueda inspeccionar fácilmente los cambios en la interfaz de usuario. Genere diagramas para visualizar los cambios de su código usando una herramienta como CodeSee Review Maps. ¡Gracias por leer y feliz codificación! También publicado aquí